Recent mobile communication devices, such as e.g. cellular phones, smartphones, PDAs, and tablets, are often equipped with various advanced technologies for handling and using sensitive information. An example of such technologies is the combination of NFC and Secure Elements, which may e.g. be used in connection with various payment applications which involve use of sensitive information, such as credit card information, bank account numbers, passwords etc. This sensitive information has to be protected but at the same time the applications need to be able to access the relevant secure functions in order to serve their intended purpose.
Some mobile device operating systems, such as the Android-based operating systems, include functions for authenticating applications. This may be done by determining whether the application is genuine, i.e. by validating that the application has been signed by the application provider. However, the number of secure functions which an application actually needs to access may differ in dependence on its specific purpose. Accordingly, simply giving an application access to all or none of the secure functions may constitute a security risk in cases where an application is allowed to access more secure functions than it actually needs. Furthermore, when a new application provider enters the market, authentication of applications provided by the new provider will not be possible until the mobile operating system has been updated to include the corresponding certificate.
In view of the above, it has been suggested to let a trusted third party (also referred to as a Trusted Service Manager or TSM) sign the applications with keys corresponding to the functions or sets of functions which the application needs to access. By storing corresponding certificates in the operating system of the mobile device, the mobile device may determine whether an application's request for accessing a particular function should be allowed by verifying whether the application has been signed accordingly. Although this approach overcomes many of the problems described above, it still suffers from some drawbacks.
One drawback is that the access certificates are pre-installed as part of the mobile device operating and may therefore not be accessible to the TSM in case the TSM needs to manage the certificates, e.g. upon expiry of a certificate or in order to delete, replace or add a new certificate. Thus, an over-the-air (OTA) update is required to perform the desired certificate management.
A further drawback is that it is difficult to change application permissions once these have been granted by signing the application at the TSM. More specifically, a removal or change of access permissions for one or more installed applications while other applications are still allowed access will require that these other application are signed anew with new (valid) certificates. Again, an additional OTA which involves OEM (original equipment manufacturer) and/or MNO (mobile network operator) interaction is required to update the access certificates.
Finally, having different TSMs (and hence different access certificates) in different geographical regions forces the OEM to provide different (i.e. region-specific) operating system image builds.
There may accordingly be a need for an improved way of controlling application access to secure functions of mobile devices without the drawbacks described above.